LGTM. Major bump from 6.1.0-beta.1 → 7.0.0-beta.1 is the correct semver signal — the ⚠ BREAKING CHANGES entry (media_buy_status now drives lifecycle; status is the task envelope) lands via #846, so release-please picked the right tier.

Things I checked

• Version triple is consistent: .release-please-manifest.json → 7.0.0-beta.1, CHANGELOG.md heading → [7.0.0-beta.1], pyproject.toml → 7.0.0b1.
• PEP 440 normalization commit (da125d2) converts the SemVer 7.0.0-beta.1 to the wheel-installable 7.0.0b1. pip / PyPI require the b1 form; release-please emits the hyphenated form. Normalization-on-top is the established pattern for this repo.
• BREAKING CHANGE is real and already on main (#846 merged at 5defa15). Major bump is earned, not noise.
• Diff is scoped to the three release-please-owned files. No source under src/adcp/ touched, no generated-type churn, no public-API surface change in this PR.

Follow-ups (non-blocking — file as issues)

• Every release-please beta PR will regenerate 7.0.0-beta.1-style strings and require a manual PEP 440 normalization commit. Worth teaching release-please to emit 7.0.0b1 directly (custom versioning strategy or a prerelease-type config) so this stops being a manual step on every prerelease.

Safe to merge.

LGTM. Release-please scaffolding, version pin is correct.

Things I checked

• .release-please-manifest.json is 6.1.0-beta.2, pyproject.toml is 6.1.0b2 — the SemVer/PEP 440 split is intentional and matches the rest of the toolchain (manifest uses release-please's internal SemVer form, wheel uses PEP 440 short-form).
• prerelease: true + prerelease-type: beta in release-please-config.json makes 6.1.0-beta.1 → 6.1.0-beta.2 a clean prerelease bump.
• CHANGELOG entry preserves the ⚠ BREAKING CHANGES callout for media_buy_status, so beta consumers still see the migration note even though the override keeps the version on the 6.1 beta line. Right call for a beta series — opt-in consumers accept churn, and the breaking note is what they actually read.
• The two override commits (normalize prerelease version to PEP 440, keep release on 6.1 beta line) reverse the initial 7.0.0-beta.1 autogenerate cleanly — no orphan tag or manifest drift.

Notable choice rather than a finding: collapsing a flagged breaking change into a prerelease patch bump is a maintainer judgment call that's only defensible because the version is still pre-1.0-stable beta. Worth being explicit in a follow-up about when the 6.x → 7.0 cut actually happens, so release-please isn't fighting the maintainer again next cycle.

Safe to merge.

Release PR reviewed: corrected to stay on the 6.1 beta train and pyproject.toml uses the PEP 440 version 6.1.0b2.

LGTM. Release-please autorelease — manifest, CHANGELOG, and pyproject.toml all converge on 6.1.0-beta.2.

Things I checked

• .release-please-manifest.json:2 → 6.1.0-beta.1 → 6.1.0-beta.2. Matches pyproject.toml:7 (6.1.0b1 → 6.1.0b2). PEP 440 form is the right shape for the manifest's SemVer form.
• CHANGELOG.md:4-23 is auto-generated entry. Lineage cited: #843, #841, #845, #847, plus 391dae6, 5defa15, 532459a. No hand-edits.
• CHANGELOG.md:7 carries a ⚠ BREAKING CHANGES note (media_buy_status as lifecycle, status as task envelope) while the version stays on the 6.1 beta line — deliberate override per 01f7f76 (chore: keep release on 6.1 beta line), which superseded release-please's initial 7.0.0-beta.1 bump in 327e649. Beta line policy: breaking changes are allowed without a major bump. No semver block.
• Conventional-commit CI gate passed. Downstream import smoke passed. v3 reference seller pytest passed. GitGuardian clean.
• No public-API source changes in this diff — the breaking change cited in the changelog landed in the commits the changelog references, not here.

Follow-ups (non-blocking — file as issues)

• The two harden media buy response normalization bug-fix entries (5defa15, 532459a) are identical headlines on adjacent commits. Worth a one-line note in the next release explaining whether one supersedes the other, or squashing the changelog line.
• Adopters reading ⚠ BREAKING CHANGES against a 6.1.0-beta.2 version will reasonably wonder why the major didn't move. A CHANGELOG.md preamble — or a short note in the next stable release — stating the beta-line policy (breaking changes permitted pre-1.0 stable) would save the question.

Safe to merge once the in-flight CI legs (Test Python 3.10–3.13, Postgres conformance, storyboard runners, schema validation) land green.

Release PR reviewed after latest release-please rerun: version stays on 6.1.0-beta.2 and pyproject.toml uses 6.1.0b2.

LGTM. Release-please bumps 6.1.0-beta.1 → 6.1.0-beta.2; the manual override commit keeps the train on the 6.1 beta line instead of cutting 7.0.0-beta.1.

Things I checked

• pyproject.toml 6.1.0b2 (PEP 440) lines up with .release-please-manifest.json 6.1.0-beta.2 and the CHANGELOG.md heading — three-way version coherence holds.
• The BREAKING CHANGES note in the changelog (media_buy_status for lifecycle) is the reason the bot originally proposed 7.0.0-beta.1; the chore: keep release on 6.1 beta line override consolidates it into the beta cycle, which is a defensible call while we're still pre-cut.
• No source changes — pyproject version + manifest + CHANGELOG only. No public-API surface, no generated types, no decisioning paths touched.
• PR labeled autorelease: pending; release-please will pick this up on merge and publish.

Follow-ups (non-blocking)

• The two harden media buy response normalization fix entries land back-to-back in the changelog because the bot dedupes by commit, not by message. Worth a one-liner in the release notes when 6.1.0 ships final, so adopters know it's one fix, not two.
• Whenever 7.0.0 actually cuts, the accumulated BREAKING CHANGES entries from the 6.1 beta line need to make it into the migration note — they're easy to lose when the version override skips the major bump that would otherwise force the conversation.

One dry observation: overriding a release-please proposal in a commit on the release PR itself is a notable pattern — works, but the next person reading git log on .release-please-manifest.json won't find the rationale anywhere except this PR thread.

Safe to merge.